When packets are sent in an environment where packet loss occurs, retransmitting the lost packets enables data transmission of a high service quality. Methods providing the framework for retransmission in RTP (Realtime Transport Protocol) include sending/receiving methods for stream packets, such as W-RTP (Wireless-RTP) and RTP/RX. In W-RTP and RTP/RX, a request for retransmission of lost packets is sent from the receiving terminal using the RTCP (RTP Control Protocol) and in response to that retransmission request, the sending terminal retransmits the RTP packets (see A. Miyazaki et al., “RTP Payload Format to Enable Multiple Selective Retransmissions”, Internet Draft, draft-miyazaki-avt-rtp-selret-01.txt, Internet Engineering Taskforce, July 2000, and K. Yano et al., “RTP Profile for RTCP-based Retransmission request for Unicast session”, Internet Draft, draft-podolsky-avt-rtprx-01.txt, Internet Engineering Taskforce, March 2000).
On the other hand, RFC2733 defines a technology for recovering lost packets by FEC (Forward Error Correction) (J. Rosenberg et al., “An RTP Payload Format for Generic Forward Error Correction”, RFC2733, Internet Engineering Taskforce, December 1999). With the technology disclosed in JP 2001-045098A, to enable the selection of the reception rate and robustness suited for the respective reception environments of the receiving terminals in a multicast environment, hierarchical encoding of the data is adopted on the sending side and if necessary the receiving terminals use FEC data. The receiving terminals monitor send/receive conditions such as the packet loss rate, the transmission rate, and the reception rate, and calculate the ratio of the reception rate to the transmission rate, that is, the send/receive rate. Furthermore, they determine the hierarchy of the data to be received and whether the reception of FEC data is necessary in accordance with the packet loss rate and the send/receive rate.
The above conventional technologies have experienced various types of problems, including the following.
First Problem
Retransmission must be restricted (1) when the sending terminal or transmission path is overloaded; (2) when retransmission is restricted to secure a band for the sending of stream packets so as to send the stream packets to even more receiving terminals; and (3) when different services are provided by distinguishing whether or not to perform retransmission at each receiving terminal. W-RTP and RTP/RX do not have a function for interrupting the request for retransmission even in these cases, so receiving terminals continue sending retransmission request packets, which wastes bandwidth.
Second Problem
With W-RTP and RTP/RX, if the sending terminal receives numerous retransmission request packets from a plurality of receiving terminals at once, then the sending terminal or the transmission path may become momentarily overloaded, which can negatively affect the sending of data packets by the sending device.
Third Problem
Let us assume that a transmission path for packets has a wired section and a wireless section. Generally speaking, the cause of loss in wired sections and wireless sections is different. Packet loss in wired sections is caused by congestion, and thus there is the possibility that the congestion is further exacerbated by the requests for retransmission. Consequently, when there is packet loss in wired sections, it is necessary that the transmission rate of the packets is lowered or a process for not executing the retransmission request is performed when making a retransmission request. The cause of packet loss in wireless sections is the disposal of packets by the receiving terminal due to bit errors. Therefore, the packet loss rate does not change even if the method for retransmission on wired sections is used and the transmission rate of the packets is lowered in accordance with the retransmission request, and the result is a continual decrease in the packet transmission rate. Accordingly, when making a retransmission request, the receiving terminals must distinguish and separate the section experiencing the loss and switch the method for requesting retransmission depending on whether the loss is in a wired section or whether the loss is in a wireless section.
However, RTP/RX does not include a method for distinguishing between packet loss in wired sections and packet loss in wireless sections. W-RTP is capable of changing the SSN (Second Sequence Number) of the W-RTP packets in the gateway at the boundary between wired sections and wireless sections so as to not make a request for retransmission regarding packets lost in wired sections. However, W-RTP is a method in which the packet format of the RTP is changed, and therefore to receive streams from a sending terminal sending conventional RTP packets, the sending terminal must be changed to send W-RTP packets or there must be a conversion process for converting RTP headers into headers for W-RTP at the gateway.
Fourth Problem
The operation must be switched because of packet loss not only in the case of retransmission but also when controlling the transmission rate and adding robustness to the data packets. In case of packet loss caused by congestion, the transmission rate must be lowered to avoid congestion, but when packet loss results from transmission errors, the error rate cannot be changed by lowering the transmission rate, so rather that lowering the transmission rate is meaningless, and instead the robustness added to the data packets should be made stronger.
With the technology of JP 2001-045098A, the packet length even of packets experiencing transmission errors must be known for the receiving terminal to monitor the reception rate. Yet there is the possibility that errors may occur in the field indicating the packet length, and therefore the accurate reception rate cannot be determined. Furthermore, it is not possible to determine from the send/receive rate ratio how much packet loss actually occurred in the wireless sections, so it is difficult to determine how much robustness to add (that is, determine the threshold value of the send/receive rate ratio).